Method of sharing personal media using a digital recorder

ABSTRACT

A method and apparatus for sharing personal media using a digital recorder allows a plurality of multimedia devices to view content stored on a DVR across a local network. The DVR records video content from broadcast signals and records video content downloaded via the Internet.

CROSS-REFERENCE TO RELATED APPLICATIONS; PRIORITY CLAIM

This application is a continuation of Non-Provisional application Ser.No. 10/742,581, filed Dec. 18, 2003, which claims benefit of ProvisionalAppln. Ser. No. 60/434,767, filed Dec. 18, 2002, the entire contents ofthe aforementioned applications are hereby incorporated by reference asif fully set forth herein, under 35 U.S.C. § 119(e). Appln. Ser. No.10/742,581 also claims benefit as a Continuation-in-part of applicationSer. No. 10/220,558, filed Aug. 29, 2002, which further claims benefitof Provisional Appln. Ser. No. 60/186,551, filed Mar. 2, 2000, theentire contents of the aforementioned applications are herebyincorporated by reference as if fully set forth herein, under 35 U.S.C.§ 120. The applicant(s) hereby rescind any disclaimer of claim scope inthe parent application(s) or the prosecution history thereof and advisethe USPTO that the claims in this application may be broader than anyclaim in the parent application(s).

FIELD OF THE INVENTION

The invention relates to personal multimedia service. More particularly,the invention relates to a method and apparatus for sharing personalmedia using a digital recorder.

BACKGROUND

With the advent of videocassette recorders (VCRs), TV viewers are ableto record TV program events that are broadcasted in a given time slotand playback the recorded program content later. During the recording, aVCR changes the electrical signals of a program content into magneticsignals and stores the magnetic signals on magnetic tape. When playingback, the VCR changes magnetic signals into electrical signals and theattached TV set displays the program content of the signals on itsscreen.

With the development of digital technology, the VCRs are beingsuperseded by digital video recorders (DVRs). Like a VCR, thefunctionality of a DVR is to record broadcasted program events for laterplayback. During recording, a DVR changes the electrical signals ofbroadcast program content into digital information, such as MPEG datastreams, and stores the digital information in a memory device ordirectly stores the pre-digitized TV signals in the memory. When playingback, the DVR converts the digital information back to analog signals.An attached TV set displays the program content of the signals on itsscreen.

To record TV program events using a VCR, a user must manually select achannel and control the VCR or have someone else perform the operation.By using a DVR, however, the user may establish a program recordingsequence by programming the DVR according to a TV program guide and havethe recording performed automatically.

Although the DVR enables users to specify the recording time, channel,and duration for a plurality of events, it cannot meet the increasingneeds in defining and capturing the program events in a more intelligentway. For instance, in situations where a user is far away from his DVRand TV set, he will be unable to program his DVR and record the programevents that he likes.

What is desired is to establish a communication system through which auser may access to a centralized TV program guide database and programhis DVR anywhere.

Additionally, such a system would provide a user with the ability totransfer recorded program material from one DVR to another DVR, or aserver to a DVR, in a secure manner that preserves the program materialprovider's copyrights.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 is a block diagram illustrating a communication system for remoteaccess to a centralized personal television service;

FIG. 2 is a data flow diagram showing the operational processes of thesystem shown in FIG. 1;

FIG. 3 is a table diagram illustrating the structures of a user databaseand an event database shown in FIG. 2;

FIG. 4 is a flow chart showing a process used by a personal TV service'sWeb server to obtain remote programming directives from a user;

FIG. 5 is a pictorial representation of a graphical user interface forprogram selection;

FIG. 6 is a screen capture of a Now Showing Web page that appears in auser's web browser or television screen;

FIG. 7 is a block diagram illustrating the interactions among thepersonal TV service center, the DVR, and the external content serverover Internet;

FIG. 8 is a screen capture of a replay bar indicating that the contentis downloading faster than playback speed;

FIG. 9 is a diagram illustrating a digital certificate containing DVRinformation;

FIG. 10 is a block diagram illustrating a media server in a localnetwork connected to DVRs within a home;

FIG. 11 is a block diagram illustrating a communication exchange betweentwo DVRs to create a strong encrypted connection;

FIG. 12 is a diagram illustrating a digital certificate containing DVRand content server information;

FIG. 13 is a block diagram illustrating a server recording DVR accessinformation for billing purposes;

FIG. 14 is a block diagram illustrating a domain name redirector thatredirects a DVR request to a third party server;

FIG. 15 is a block diagram illustrating a DVR being used as anencryption pipeline for a third party content server;

FIG. 16 is a screen capture of a Now Playing screen showing anaccessible media server;

FIG. 17 is a screen capture of a content screen showing accessiblecontent for a media server;

FIG. 18 is a screen capture of a transfer options screen showing forcontent from a media server;

FIG. 19 is a screen capture of a program status screen showing a programbeing transferred from media server;

FIG. 20 is a screen capture of a music screen showing accessible musicfrom a media server;

FIG. 21 is a screen capture of a photo screen showing accessible photosfrom a media server;

FIG. 22 is a block diagram illustrating a media server in a localnetwork connected to a DVR within a home with the media server havingInternet access; and

FIG. 23 is a block diagram illustrating a media server in a localnetwork connected to a DVR within a home with both the media server andDVR having Internet access.

DETAILED DESCRIPTION

A method and apparatus for sharing personal media using a digitalrecorder is described. In the following description, for the purposes ofexplanation, numerous specific details are set forth in order to providea thorough understanding of the present invention. It will be apparent,however, that the present invention may be practiced without thesespecific details. In other instances, well-known structures and devicesare shown in block diagram form in order to avoid unnecessarilyobscuring the present invention.

In the following discussion, in references to the drawings like numeralsrefer to like parts throughout the several views.

A. System for Remote Access to Personal TV Service

Referring to FIG. 1, a communication system for remote access to apersonal TV service is shown, generally designated as 100. In accordancewith one approach, a digital video recorder (DVR) 110 installed in ahousehold communicates with a personal TV service center (hereinafterreferred to as service center) 130, which provides program guide data,graphical resources (such as fonts, pictures, etc.), serviceinformation, and other forms of data that enable the DVR 110 to operateindependently of the service center 130 to satisfy viewer interests. Thefunctionality of a DVR is typified in U.S. Pat. No. 6,233,389 which isowned by the Applicant and is hereby incorporated by reference. Thecommunication system uses a secure distribution architecture to transferdata between the DVR 110 and the service center 130 such that both theservice data and the user's privacy are protected. The DVR 110 receivesbroadcast signals from an antenna 115 or receives television signalsfrom a cable TV system.

In one embodiment of the invention, the DVR 110 generally comprises: aplurality of components that are necessary to digitize an analogtelevision signal and convert it into a digital data stream; a pluralityof components that are designed to record segments of said data stream;a plurality of storage facilities that are designed to retain segmentsof said data stream; a plurality of components that are designed toretrieve segments of said data stream, convert said data stream into ananalog signal, and then modulate the signal onto a RF carrier, throughwhich the signal is delivered to a standard TV set 120; and an interface125, through which the DVR 110 communicates with a network 140.

The DVR 110 contains a local secure crypto chip that that contains anon-alterable private key. The DVR 110 secure functionality is furtherdescribed in U.S. Pat. No. 6,385,739 which is owned by the Applicant andis hereby incorporated by reference.

The DVR 110 may be directly connected to the service center 130 by usingits internal telephone modem to dial into an incoming call modem bank145. The incoming call is first routed to the service center 130 foridentification verification. Upon verification, the incoming call isauthorized. The private modem bank 145 answers the call and the DVR 110is granted access to the databases in the service center 130.

Alternatively, the DVR 110 may be indirectly connected to the servicecenter 130 via the network 140. The interface 125 between the DVR 110and the network 140 may be the internal telephone modem of the DVR 110,or a dedicated network interface such as a cable modem. The computernetwork 140 can be either a private network or the Internet. The DVR 110initiates a connection to the computer network 140 by calling a localaccess telephone number for an Internet service provider (ISP). The ISPdirects the network connection request to the service center 130 foridentification verification. Upon verification, the network connectionis authorized and the DVR 110 is granted access to the databases in theservice center 130.

The service center 130 receives program schedule information 150 fromexternal sources. The program schedule information 150 forms the basisof a program guide that TV viewers can use to select TV programs to berecorded. The service center 130 communicates with the computer network140 through an interface 135.

TV viewers can use a remote computer 155 or personal digital assistants160 to remotely access the program database in the service center 130 byestablishing a communication channel with the service center 130 via thecomputer network 140.

Referring to FIG. 2, the service center 130 includes a Web server 200,which collects, organizes, and provides program schedule information; aprogram database 210, which stores program schedule information; a userdatabase 220, which stores information about users and digital videorecorders; an event database 230, which stores an event list for eachuser, and a dispatch process 240, which traverses the user database andretrieves the event list from the event database. It may also include anetwork interface over which the Web server and the digital videorecorder communicate.

In one embodiment, the DVR 110 includes a micro-server 250, whichcontrols the communication between the DVR 110 and the service center130; a local program storage guide 260, which records the program guideprovided by the service center 130 and is updated whenever the DVR 110accesses the service center 130; an event queue 270, which is a datastructure used to initiate recording sessions that capture selected TVprograms; a pseudo-random-number-generator (PRNG) 280, which generatesan authorization key for remote access; as well as a network interface125, which connects the DVR 110 to the computer network 140. The eventqueue 270 is coupled to a recording device integral to the DVR 110.

Both the remote computer 155 and the personal digital assistants (PDA)160 comprise a Web browser 290, which may be a generic Web browser thatenables the user to view Web pages.

FIG. 3 is a table diagram illustrating the structures of a user database220 and an event database 230. The user database 220 includes aplurality of user records 300. Each user record 300 comprises aplurality of fields, among which are a user identification 310, acrypto-key 320, a DVR identification 330, and an event list pointer 340.The user identification field 310 is used as a key into the userdatabase 220. The crypto-key field 320 is used to store theauthorization key received from a user who is attempting to program hisDVR 110 remotely. The DVR identification 330 is used to store thenetwork address and connection details which are needed to establish acommunication channel with the DVR 110.

In the user database 220, separate event lists 350 are maintained foreach user. The event lists 350 are stored in the event database 230.Each event list 350 includes a plurality of event records 360. Eachevent record includes a plurality of fields among which are a time field370, a channel field 380, and a duration field 390. The time field 370is used to indicate a start time for recording and is comprised of thedate and time of the program event. The channel field 380 specifieswhich channel the DVR should record. The duration field 390 is used tospecify how long the DVR should record the content for that programevent. An event record can also contain an ID of a record (or object) inthe program guide database. The DVR retrieves necessary information fromthe program guide database.

B. Process for Remote Access to Personal TV Service

FIG. 2, together with FIG. 1, shows various processes that collectivelyenable the functionality of the techniques described herein.

The service center 130 receives program schedule information 150 fromexternal sources on a periodic basis. Once the program scheduleinformation 150 arrives, the program database 210 is updatedaccordingly.

The DVR 110 updates its local program guide 260 on a periodic basis byreading a Web page from the Web server 200 or via cable, satellite, ortelephone. In response to a request from the DVR 110, the Web server 200first consults the program database 210 for updated program informationand then dynamically creates a Web page containing updated programschedule information.

Two types of remote access are available: direct and indirect. The TVviewer can indirectly program the DVR 110 by using a Web browser 290 oneither a remote computer 155 or a personal digital assistant 160. Inthis situation, the Web browser 290 is used to access a special Web sitehosted by the Web server 200. The Web server 200 presents to a TV viewera program guide using a graphical user interface as shown in FIG. 5. TheTV viewer selects TV programs by program title and time slot to indicatewhat programs should be recorded by the DVR 110.

The service center 130 executes a dispatch process 240 on a periodicbasis. The dispatch process 240 traverses the user database 220.Whenever the dispatch process 240 encounters a user who has specifiedprogram events, the dispatch process 240 retrieves the event list 350from the event database 230. The dispatch process 240 then establishes acommunication channel with the micro-server 250 that resides in the DVR110. This communication channel is designed to allow the dispatchprocess 240 to retrieve a special event-dispatch Web page from themicro-server 250. The micro-server 250 presents the event-dispatch Webpage to the dispatch process 240. The dispatch process 240 thencompletes the event-dispatch Web page and submits it back to themicro-server 250.

The micro-server 250 can also cause the dispatch process 240 to startthe event transfer by polling the dispatch process 240 for events.

The micro-server 250 uses event directives found in the event-dispatchWeb page to update the event queue 270 integral to the DVR 110. Theevent queue 270 is a data structure used by the DVR 110 to initiaterecording sessions that capture TV program events.

In order to authenticate a transaction, the Web server 200 includes oneor more authorization codes for the user affiliated with the DVR 110 tobe programmed. The DVR 110 compares the authorization code against aprivate copy maintained in the DVR's non-volatile memory. Theauthorization codes are time sensitive and can be set to expire assystem security requirements dictate.

To use the direct remote access feature, a user must first obtain anauthorization key from the DVR 110, which is generated by thepseudo-random-number-generator (PRNG) 280. The user communicatesdirectly with DVR 110 via his television at the DVR's location. The DVR110 presents the authorization key to the user. The user later accessesthe DVR 110 through the Internet using his computer 155 or his PDA 160.The user presents the authorization key and programs the DVR 110 througha graphical user interface that is managed by the micro server 250.Also, once the user has access in direct mode, the user can download aprogram to the DVR 110.

C. Process to Obtain Remote Programming Directives

FIG. 4 is a flow chart showing a process used by the Web server 200 andmicro server 250 to obtain remote programming directives from a user.Both are presented in parallel, but in normal use are separateprocesses. The process includes the steps of:

Step 400: The Web server 200 or micro server 250 presents anauthorization request form in the first Web page to the user whoaccesses a special Web site that is managed by the Web server 200 or themicro server 250;

Step 410: The Web server 200 receives an authorization password enteredby the user; the micro server 250 receives an authorization key from theuser;

Step 420: The Web server 200 validates the authorization password usingthe user database 220; the micro server 250 validates the authorizationkey with the key that it has stored.

Step 430: Once the Web server 200 has validated the authorizationpassword in the user database 220, it writes a cookie in thenon-volatile memory of the remote computer 155 or personal digitalassistant 160; once the micro server 250 has validated the authorizationkey, it writes a cookie in the non-volatile memory of the remotecomputer 155 or personal digital assistant 160;

Step 440: The Web server 200 or micro server 250 presents a programguide to the user after the user is identified and authenticated;

Step 450: The Web server 200 receives the user selections and creates anevent list 350 specific to the user. The event list 350 is stored in theevent database 230. The micro server 200 receives the user selectionsand places them on the event queue 270.

In Step 440, the Web server 200 or micro server 250 follows a scriptintegral to the first Web site presented to the user and searches for avalid cookie on the remote computer 155 or the personal digitalassistant 160. Once a valid cookie is discovered, steps 400 through 430are excluded from the process flow.

D. Graphical User Interface for Program Selection

FIG. 5 is a pictorial representation of an exemplary graphical userinterface (GUI) 500 for program selection. The GUI 500 is used both onthe DVR front panel and is incorporated into the Web pages presented toremote users by the Web server 200. When implemented directly in the DVR110, the GUI 500 is manipulated directly by the control process integralto the DVR 110. When the GUI 500 is presented to the remote users via acomputer network, it embodies as an active server Web page. FIG. 6 is ascreen capture of the Now Showing Web page that appears in a user's webbrowser.

The GUI 500 comprises a table 505 that contains a plurality of columns510 and a plurality of rows 515. The columns 510 correspond to the daysof the week (and a specific calendar date). The rows 515 correspond tothe hours of a given day. The columns 510 and rows 515 of the table 505are actually made up of data selection controls where the caption of thecontrol is set to indicate the title of a TV program that is scheduledin the time slot according to the position of that control in the table505. The GUI also comprises a mechanism for scrolling up 520 andscrolling down 525, a mechanism for turning forward 530 and turningbackward 535; a mechanism for selecting a specific TV program; amechanism for creating a program event list 350 which contains selectedTV programs; and a mechanism for editing said event list 350. Inaddition, it may also include a mechanism for commanding download, amechanism for indicating the download is in progress, and a mechanismfor canceling the ongoing download.

The position of the control corresponds to the day and hour of the TVprogram event. The user can toggle the selection controls that arepresented in the GUI 500. When the GUI 500 is returned to the Web server200, the identifiers of the selected controls are used in conjunctionwith the program guide 260 to create an event list 350 for the user. Theevent list 350 is then stored in the event database 230 in the case ofremote programming. For local programming of the DVR 110, the event list350 is stored directly in the event queue 270 that controls the DVRrecording sequence.

E. Internet Access to Digital Video Recorder

FIG. 7 is a block diagram of a general scheme 700 illustrating theinteractions among the service center 130, the DVR 110, and the externalcontent server 720 over the Internet, wherein a particular style of theInternet access is integrated into the DVR 110 to enable it to fetchcertain types of content over an Internet connection 140 and make themavailable for viewing in the Now Showing page as shown in FIG. 6. Forpurposes of illustrating a clear example, FIG. 7 and the descriptionherein refers to specific elements and protocols that may be used in animplementation, such as the Internet, Linux, DHCP, etc. However, otherfunctionally similar elements or protocols may be used in alternativeimplementations. For example, downloading may occur through any public,private, or dedicated network rather than the Internet. Other operatingsystems and dynamic addressing protocols may be used.

In a Now Showing page, a listing of the content name, i.e., the title ofTV program, indicates that such content is being fetched on the GUI 500,and a record icon, or some variant thereof, indicates that the downloadis in progress. The viewer may pick the content (i.e., the TV program)and play it at any time.

The download may occur at any speed. Thus, the interface 125 in FIG. 1is not dependent in any way on speed of download. FIG. 8 is a screencapture of the Web page showing a replay bar 801 that, by growing thegreen region 802 to match, indicates that the content is downloadingfaster than playback speed 803. Other mechanisms than such a replay bar801 may be used to indicate that content is downloading faster thanplayback speed. In any case, the viewer is able to use all trick-playactions on whatever amount of content has been downloaded to that point.

The fact that the content was downloaded over the Internet istransparent to the viewer, except in the context of presenting programinformation, where an indication that the content is from the Internetmay be made in various ways.

Pointers to downloaded content are stored in a local content database740 on the DVR 110 hard drive in an analogous manner to how broadcastprograms are stored, such that all forms of searching and presentationproperly display those programs and provide for their manipulation.

In channel or network oriented contexts, downloadable programs arepresented in a manner analogous to broadcast programming. These contextsmay have to be modified such that the channel or network “lineup” ispresented in a sensible manner, since time and location are irrelevantfor such programs.

The number of content items available in the Now Showing context asshown in FIG. 6 may make navigation unwieldy. Although not required forthe initial implementation, this context may be modified to makenavigation of many items simpler.

The entity providing the content from some servers may be viewed as atelevision network. Each unique server name indicates a channel. Here, a“server” is just a name on the network; it might map into any physicalserver anywhere in the world.

Once the content server 720 is contacted, the DVR 110 requests the mediacontent according to the program identification given. This is mapped bythe Web server 200 into a particular piece of content, which is thensent down the connection. Either the content server or the DVR maythrottle the download speed.

If the viewer requests multiple downloads, the DVR 110 may chooseseveral different ways to get the content; it may initiate multipleconnections with a maximum limitation, or queue requests, or both.

In one approach, elements of FIG. 7 address security of the DVR 110.Opening up a network port leads to a large number of possible securitybreaches, revolving around the security of copyrighted content andprotection of a customer's private data.

In one embodiment, standard Linux firewall support is used to managethis protection by automatically blocking access to all but a few,well-known ports (such as Web (HTTP) or discovery) in both directions ofcommunication. The well-known ports are used by the application softwareof the DVR to contact the external content server 720 for downloadingmedia content.

A dynamic addressing client software element, such as the Linux DHCPclient, is provided in the DVR 110. On boot up of the DVR, if a networkinterface is detected, then the DHCP client uses the well-known port toobtain a network address for the DVR from a source of dynamic addresses.For example, the DHCP client of DVR 110 uses the DHCP protocol to pollfor an external DHCP server 750. If no server is found, networking willbe disabled. Otherwise, the DVR 110 will initialize its networkparameters from the DHCP response.

One issue with such Linux firewall support is that the external DHCPserver 750 is required to configure the Internet access information. Itis well known that there are a large number of methods for reading dataor redirecting the data flow on an Internet connection between twodevices. One possibility is aliasing, in which a malicious DHCP serverconfigures Internet access information in a way that enables a malicioushost to enter and attack the DVR by using an alias server address.

To defeat attacks of this nature, in one embodiment all communicationwith the content server 720 is authenticated and encrypted. The contentserver 720 has access to the public key of the DVR 110, and the DVR hasa copy of the public key of the content server 720. The DVR 110 hasmetadata content information about the content server 720 downloaded bythe service center 130. The DVR 110 stores the metadata in its database740 and relies on the data in the database 740 to operate. Using acertificate exchange, the DVR 110 and the content server 720 generate aone-time session key, and all further communication are encrypted usingthe session key. In one embodiment, the Blowfish algorithm is used forencrypted session communication. The public key of the content server720 is distributed from the service center 130, which has also providedappropriate program guide references to the content server 720.

The service center 130 accepts descriptions of the content server 720.In one embodiment, such descriptions consist of server URLs, contentdescriptions, content identifications, “channel” descriptions, “network”descriptions, etc. These data are imported into a content serversdescription (CSD) database 710. A set of public keys for access to thecontent server 720 are also provided.

In order for the content server 720 to accept a connection from the DVR110, it must have access to the public key for a particular DVR. Thiskey distribution may be performed on-the-fly, or through a pre-sharedkey distribution approach. In on-the-fly key distribution, the contentserver 720 establishes an authenticated connection to the service center130, provides a DVR serial number, and requests the service center 130to provide the associated public key. Given a DVR serial number, theservice center 130 returns an associated public key. The content server720 may cache this public key. Each key has an expiration date thatindicates when the content server 720 must delete the key. The servicecenter 130 may maintain a log of all distributed public keys, forexample, for the purpose of auditing key distribution.

The service center 130 may refuse to provide the public key of aninactive DVR. Additionally, the content server 720 may respond to keyinvalidation requests from the service center 130, for instance, if aparticular DVR becomes inactive.

A media recorder 730 is a subsystem of the personal TV serviceapplication software of DVR 110. Media recorder 730 allows forsimultaneous record and playback of the downloading content. Therecorded content is stored in the content database 740 of DVR 110. Themedia recorder 730 will not be started if no permanent networkconnection is available. In one implementation, media recorder 730comprises a number of different threads.

(1) Recording Queue Thread: This thread manages a queue of networkdownload requests and implements the download policy. Initially, thismay be a simple FIFO queue maintained in the database. A recording queuepolicy object is maintained once the download policy is implemented.

(2) Fetch Recording Thread: This thread is responsible for managing aconnection with the content server 720. The Fetch Recording Threadcontacts the server, implements the authentication protocol, requeststhe desired content, and manages download of the content.

As a variation on this strategy, a program object within the personal TVservice application or media recorder 730 may indicate multiple serversto be polled for the media content. The servers are polled in order bythe Fetch Recording Thread; the first to accept a request for downloadis used. This provides for load-balancing content requests across aplurality of content servers organized in a server farm or data center.

The Fetch Recording Thread periodically stores or checkpoints its stateto an database in DVR 110. Such checkpointing allows restart of adownload after a power failure or system error at the same point in themultimedia content at which download was occurring when the failure orerror happened. The Fetch Recording Thread also manages the state ofdatabase objects that are used for presentation and navigation of thecontent being downloaded. For example, the Fetch Recording Threadmanages the state of the recording object for proper display in the NowShowing context as shown in FIG. 6. There may be one or more suchthreads active at any point in time.

F. DVR to DVR Interactions

In one approach, a mechanism for transferring media and databaseelements between two DVRs is provided. Referring to FIG. 7, one exampleof a transfer is shown using a smaller amount of disk storage asprovided in a portable DVR 760, for example. As an example, before goingon vacation, a user may transfer desirable media and the invisibleassociated service data to the portable DVR 760 and take the portableDVR 760 along such that the media may be used when desired. Anotherexample of a transfer is shown using two DVRs, DVR 110 and DVR 770, thatare slaved together such that two media streams are played with precisesynchronization to achieve identical operation.

There are many ways to connect two DVRs. In one embodiment, the outputof the source DVR 110 is coupled into the input of the destination DVR770. While this method is functional, this method fails to transfermetadata information about the media stream, which is essential toviewer satisfaction in managing and using the media stream.

The media stream stored in the DVR 110 consists of the media contentitself, and a database object which provides descriptive informationabout the media content. If a data transfer method is used, such as anetwork (e.g., IEEE 802.3) or a direct connection (e.g., IEEE 1394),then both the media content and the descriptive information can betransferred, such that the integrity of the viewer experience ispreserved.

Content owners are concerned about potential theft of their content. Afurther approach encrypts the data transfer between the DVRs 110 and770. This can be done in a number of standard and custom ways. Forinstance, the Diffie-Hellman secure connection protocol may be used togenerate a one-time key that is then used to encrypt the transfer.

If it is desirable to allow the transfer to only occur to certainspecified DVRs, an integrated security system may be used. The publickey of each DVR is known to the other, either through pre-sharing keysor a dynamic exchange of keys. When the transfer is started, the DVRsexchange signed certificates that are encrypted based on the public keyof the other DVR. If both DVRs can decrypt and verify the signature ofthe other, then each DVR has authenticated the other's identity and canproceed to establish a one-time session key that is then used to encryptthe data during the transfer.

Key distribution in such a case may be handled through the servicecenter 130. A viewer may contact the service center 130, and requestthat two DVRs 110 and 770 he owns be authorized for data transferbetween each other. The service center 130 sends an authorization objectcontaining each DVR's public key to the other DVR through an appropriatedownload mechanism. The service center 130 maintains a record of thisoperation for later auditing purposes, which includes identifyinginformation for each DVR. For instance, should the security system bedefeated in one DVR and the public key of the other be exposed, it ispossible to modify other DVRs such that they appear authorized to thesource DVR 110. Each DVR keeps a record of the transfers. This record isuploaded to the service center 130. Later, this information could beprocessed to look for copy protection violations, copies to unauthorizedDVRs, etc.

If the transfer is interrupted, the destination DVR 770 marks the mediastream as “partial” in the descriptive object. Later, the transfer maybe restarted. Since the design of the database system guarantees themedia stream can be uniquely identified on the destination DVR 770, thepartial stream is found, and the transfer begins from its end, thusavoiding re-transfer of media that has already been stored. Once theentire media stream is stored, the descriptive object is updated to showa complete media stream.

Transferring digital data between the DVRs may take place at whateverspeed is appropriate. For instance, it may be the case that the networkbetween the DVRs is slow, in which case the transfer duration will belonger than the playback duration of the content. Alternatively, thenetwork may be fast, in which case multiple media streams might betransferred in much less time than taken for playback of one contentitem. The viewer on the destination DVR may start viewing the mediastream as soon as the first portions are available, in parallel with theongoing download of the stream.

There is no requirement that the source or destination DVR be a completedigital video DVR. For instance, the media streams stored on a server ina cable head end may be transferred reliably to the destination DVR 770.Alternatively, the media stream stored in the source DVR 110 may betransferred to a head-end server.

For example, a PC can use a USB dongle containing the crypto chip fromthe DVR. The PC establish a secure mechanism for transferring content toand from the PC. The PC would appear to be a DVR to other DVRs, becauseit would use the USB dongle to authenticate and generate encryptionkeys. Content can then be stored on the PC in encrypted form. Thecontent can be emailed to other PCs or DVRs. The other PCs must have aUSB dongle to decrypt the content. Certificates that are passed from theservice center 130 to the PC are stored in NVRAM on the USB dongle sothe certificate moves with the dongle and is not stored on the PC's harddrive.

Certain media distribution architectures, such as digital satellitesystems, broadcast most media content in an encrypted state. Using alocal decryption facility based on a smart-card, the media content isdecrypted only if it is viewed, thus protecting the content from theft.It is possible for the DVR to save these encrypted media streams todisk, and to initiate decryption upon playback. This method may be usedto transfer media streams between two DVRs. In order to properly complya particular set of content protection rules associated with the mediastream (such as play once, expire after one day, etc.), the DVRmaintains with the database object describing the media stream the copyprotection information associated with the media stream (includingwhether the stream is stored encrypted).

The content protection rules associated with the media stream may betransferred to the destination DVR 770 as well. For example, the DVR 110may have stored a movie from the content server 720 that will not bedecrypted until it is viewed. If the viewer wishes to have this mediastream transferred, it is copied into the media region of thedestination DVR 770, and the descriptive object is transferred as well.In this approach, the original information in the media stream isfaithfully duplicated to the destination DVR 770.

The smart-card might be pulled from the source DVR 110 and installed inthe destination DVR 770. When the media content is viewed, the viewer isproperly charged and all copy protection rules followed. The originalmedia content and descriptive information might, or might not, beremoved. For instance, in a “view-once” scheme, the originals aredestroyed, whereas in a “charge-per-view” scheme, they are not.

Using the same techniques as described above, a secure, or authenticatedand secure, connection may be established between two or more DVRs usinga network or modem connection. Establishing such a connection enablescontrol interactions to take place. Some examples of controlinteractions that may be provided in various embodiments are:

(1) Synchronized playback. A viewer may control trick-play features on aparticular media stream. Each key event is also passed to thedestination DVR 770, which automatically performs the same action. Forexample, a presenter may give a live presentation using the source DVR110 as a multimedia playback device, and an audience at a remotelocation can watch the same presentation given in the same way at thesame time. Alternatively, two viewers communicating through some othermeans, such as a telephone, may interact, while one or the othercontrols the playback on both DVRs of the same program. This alternativeapproach allows precise discussion of the program of interest. The meansof communication may be a simple chat program overlaid on the display inwhich the participants type comments. Such an approach may be used forbusiness presentations as well as for entertainment purposes.

(2) Link passing. A viewer of the source DVR 110 may indicate that aparticular program shall be linked to the destination DVR 770. Inresponse, the source DVR 110 sends a message to the destination DVR 770which causes the destination DVR to schedule recording of the linkedprogram. Alternately, the program may be unlinked as well. A message forlinking or unlinking may contain only the program identification,assuming both DVRs 110 and 770 are in service. If the destination DVR770 is not in service, then the message for linking may containadditional metadata.

(3) Sound or graphics effects. When the viewer takes an action, such aspressing a particular key sequence, the source DVR 110 may play a soundor present a graphic. The source DVR 110 also may pass that event to thedestination DVR 770 which reproduces that same sound or graphic, or adifferent sound or graphic associated at the destination DVR 770 withthe action that was taken. For instance, a child may add sounds to aprogram this way, which may be replicated for his friend on a remotedestination DVR 770. Such communication may be multi-way.

In another approach, DVRs may transfer other types of data as well. Forexample, consider a large home DVR 110 and a smaller portable DVR 760.Data such as software, graphical elements, program guide data, etc., maybe transferred between the two DVRs. For instance, the portable DVR 760may be updated or data synched by the home DVR 110 every time the twoDVRs are connected. The update may include transferring and installing asoftware update, synchronizing program information, synchronizingrecording schedules, etc. The synch is much like a PDA where theportable DVR 760 may tell the home DVR 110 to delete a program becausethe user has already viewed it. The portable DVR 760 transfers anyoperational information to the home DVR 110 whenever two DVRs areconnected, and the home DVR 110 then sends the operational informationto the service center 130 whenever the home DVR 110 accesses to theservice center 130.

The update may be done automatically. In such a case, when two DVRs areconnected, a set of pre-configured actions are performed, such asupdating program guide or software, and then media streams may betransferred as well. If the destination DVR 760 is a smaller portableunit, then not all media streams would fit. In this case, the viewer mayexplicitly choose which media streams to transfer. Alternatively,application software in the source DVR may use preference information toselect a subset of the available media of most interest to the viewerand transfer only those streams. In another alternative, media streamsare transferred going from newest to oldest, stopping when no more willfit, or oldest to newest. A season pass (where all showings of a programon a channel are recorded) may include a marker that DVR to “alwaystransfer” or “never transfer”. Another criteria may be whether theprogram was explicitly picked or chosen based on viewer preferences. Anyprogram information stored in the descriptive object for the content maybe used in the selection criteria, such as length, actors, rating, etc.The criteria can trigger actions such as “always transfer”.

G. Network Security Schema

As mentioned above, one approach herein provides a secure encrypted datatransfer between DVRs 110, 760, 770 or a content server 720 and a DVR110, 760, 770. The approach allows users to record a program on one DVR110, and then watch the program on another DVR 770.

The encrypted data transfer system described herein makes it verydifficult to transfer videos from a DVR to any incompatible system, orto a system outside the location of the first DVR. Accordingly, usersmay exercise reasonable Fair Use rights to the recordings that they havemade, but the approach makes it difficult for users to ‘pirate’ videos,or send premium content to their friends in violation of Fair Useprinciples.

Various embodiments of the approaches herein may include the followingaspects:

-   -   Recordings are encrypted. Many recordings are encrypted when        they are initially recorded. Those recordings that are not        encrypted may be encrypted before being transferred from one DVR        to another. This makes it difficult for anyone to “sniff” the        recording data as it travels through a home's network and to        make a copy of the data.    -   When an encrypted recording is transferred from one DVR to        another, the receiving system cannot use the recording unless        the sending system also transfers the encryption/decryption key        associated with that one recording.    -   A DVR may discover other systems from which it might transfer        recordings via an IP broadcast mechanism or other network        discovery protocol. In such discovery protocols, discovery        packets typically do not leave the local IP subnet. In the        residential environment, a local IP subnet comprises a home's        LAN. Additionally or alternatively, if there is a concern that a        user will try to share recordings with other users, then        application software of the DVR provides no mechanism which        would allow the system's owner to type in or otherwise manually        specify the IP address of a system located elsewhere on the        Internet.    -   A DVR may only send a recording encryption key to another DVR,        if the receiving system is “authorized” to view that recording.        For example, in this context “authorized” may mean that the        destination DVR is in the same household or is registered by the        owner as authorized. The key transfer is performed using a        robust public/private key system—in which each key transferred        is intelligible only to the one system to which it was sent.    -   The authorization is done via a digital certificate, which lists        the specific systems known to be part of one household or owned        by a single user. The certificate includes the public keys of        the systems, and is “signed” by the service provider. Each        system verifies the signature on the certificate it is using,        and also verifies its own identity against that contained in the        certificate, before transferring any data or keys to any other        system.

The certificate system can be based on the ElGamal public/private keysystem and on the Blowfish symmetric block cipher, which includesself-checking that would block attacks such as “change a system's serialnumber” or “copy a certificate to a different system” or “alter acertificate”.

Referring to FIGS. 7 and 9, a user logs onto the service center 130 tocreate a record of the DVRs that he wants to share content between.Using any appropriate user interface, the user enters the serial numbersof the DVRs that he wants included, which the service center 130verifies through its database, or the service center 130 finds theserial numbers that the user has previously registered. The servicecenter 130 can also restrict the user to only the DVRs that he is aregistered owner of by displaying only those DVRs for selection. Theuser can associate a name with each unit, e.g., living room DVR,bedroom, etc., to allow the user to easily identify a unit. The userselects the units that he wants to share or transfer media with.

The service center 130 creates a digital certificate 901 that identifiesthe user's units that he has selected. The certificate 901 includes eachunit's serial number 903, 905, and the corresponding public key 904,905. The name that the user has assigned to each unit is also crossreferenced, as indicated by name 902 in the certificate 901. Thecertificate can contain any number of units that the user identifies,including PCs with USB dongles as described above.

To ensure that the certificate 901 does not exist indefinitely, anexpiration date 907 is included in the certificate 901. A digitalsignature 908 is used so that units that receive the certificate canverify that the certificate actually originated from the service center130.

The service center 130 sends the certificate to each DVR 110, 770,listed in the certificate 901 over the network 140 (which may comprisethe internet, a LAN, or other public or private network), phone line, orsatellite connection. The certificate 901 may be encrypted using thepublic key of each destination DVR 110, 760, 770. A portable DVR 760 canconnect to the service center 130 via a network connection or phone lineto receive its certificate. Alternatively, the portable DVR 760 canreceive its certificate from a DVR 110 that it connects to.

Each DVR 110, 760, 770, verifies the certificate by decrypting thecertificate and verifying the digital signature 908 in the certificate901. Once the DVR has verified that the digital signature 908 is fromthe service center 130, the DVR finds the network locations of all peersthat are listed in the certificate 901, using a peer discovery protocol,such as Rendezvous from Apple Computer Inc. of Cupertino, Calif.

Once a DVR 110 has discovered a peer 770 in the network, it sets up anencrypted connection with the peer 770 using the peer's public key fromthe certificate 901. The encrypted connection may be “weakly” encryptedin that it is a function of two public keys, one from each peer. Eachpeer sends a message using the other's public key. A unit is designatedas the content server, in this example, the content server 720 isprovided by the service provider and is remotely located.

The content server 720 creates a more strongly encrypted connection withthe DVR 110 by creating a random strong connection key and encrypts thestrong key using the DVR's public key. The content server 720 then sendsthe encrypted strong key to the DVR 110. The DVR 110 decrypts the strongkey. In one approach, decryption may use hardware decryption elements.The two systems now share a secure key.

The user can request sending certain recorded content to the DVR 110.When the content server 720 sends a previously encrypted recording tothe DVR 110, it loads a recording key that was used to encrypt therecording from its database and encrypts the recording key using thestrong key. The content server 720 sends the encrypted recording key tothe DVR 110.

The DVR 110 decrypts the recording key using the strong key that itshares with the content server 720 and stores the recording key. Thecontent server 720 sends the recorded content that it has stored locallyto the DVR 110. The recorded content has already been encrypted when itwas originally stored locally by the content server 720. The contentserver 720 sends the recorded content without decrypting the content.

The DVR 110 writes the recorded content directly to its storage devicewithout decoding it. When the DVR plays the recorded content, it decodesthe content on the fly. The approach described herein preserves theintegrity of the recorded content because the content is in an encryptedstate during transmission and is stored encrypted on the DVR, therebypreventing any unauthorized copying of the content.

If the content server 720 sends an unencrypted recording to the DVR 110,it creates a random recording key that will be used to encrypt therecording and encrypts the recording key using the strong key. Thecontent server 720 sends the encrypted recording key to the DVR 110.

The DVR 110 decrypts the recording key using the strong key that itshares with the content server 720 and stores the recording key. Thecontent server 720 sends the recorded content that it has stored locallyto the DVR 110. The recorded content was not encrypted when it wasoriginally stored locally by the content server 720. The content server720 sends the recorded content, encrypting the content as it sends thecontent.

The DVR 110 writes the recorded content directly to its storage devicewithout decoding it. When the DVR plays the recorded content, it decodesthe content on the fly. The approach still preserves the integrity ofthe recorded content because the content is in an encrypted state duringtransmission and is stored encrypted on the DVR, thereby preventing anyunauthorized copying of the content.

FIG. 10 shows a media server 1002 in a locally networked DVR setup in ahouse 1001. In the example of FIG. 10, DVR 1003 is located in Bedroom 1,DVR 1004 is located in Bedroom 2, and DVR 1005 is located in theEntertainment room. The media server 1002 resides in the Living room.The user sends information instructing the service center 1006 that DVRs1003, 1004, 1005, and media server 1002 are authorized to share contentand associates each unit by the room in which it resides. The servicecenter 1006 creates a certificate 901 that contains the media server's1002 and each DVR's 1003, 1004, 1005, serial number and public key alongwith an expiration date and the service center's digital signature.

The media server 1002 can be a PC, DVR, or other type of content server.The user designates the media server 1002 as the main source ofmultimedia content in the local network.

The service center 1006 sends the certificate to the media server 1002and the DVRs 1003, 1004, 1005, via the Internet 1007. The media server1002 and the DVRs 1003, 1004, 1005, use the information in thecertificate to discover their peers. The DVRs 1103, 1004, 1005, discoverthat the media server 1002 is the only system that is serving content.Once the media server 1002 has established a weakly encrypted connectionwith each DVR 1003, 1004, 1005, it creates a random strong connectionkey for each DVR 1003, 1004, 1005. The media server 1002 encrypts eachstrong key using the particular DVR's public key and sends the encryptedstrong key to each DVR 1003, 1004, 1005. The DVR uses its local cryptochip to decrypt the strong key. The media server 1002 now shares asecure key with each DVR 1003, 1004, 1005.

Referring to FIGS. 16-21, each DVR has access to the media server'scontents. Referring first to FIG. 16, the user goes to the Now Playingscreen 1601 (which is the similar in format and content to the NowShowing screen in FIG. 6) and sees all media servers that the user canaccess. For example, a media server label 1602 indicates that the usercan access the DVR named “Bedroom.” The user selects the desired serverusing label 1602 and a content screen 1701 (FIG. 17) is displayed thatlists what content the media server has available. The user can requestthat certain recorded content (music, photos, video, etc.) be sent to aparticular DVR 1003 via the content screen 1701. The user can do thisremotely as described above, or through the DVR 1003 itself. The userselects the options for transferring the selected content using atransfer options screen 1801 (FIG. 18). The user can select where tostart the transfer from using a Start From option 1802. For example, thetransfer can start from the beginning of the program, from where theuser last paused, or at a certain time into the program. The user canview and transfer music content and photo content in the same manner, asindicated by screen capture 2001 of FIG. 20 and screen capture 2101 ofFIG. 21.

As described above with reference to FIG. 10, the media server 1002 cansend a previously encrypted recording to the DVR 1003. The media server1002 loads a recording key that was used to encrypt the recording fromits database and encrypts the recording key using the strong key. Themedia server 1002 can optionally encrypt the recording key for storagein its database using a local encryption key. It is normally notdesirable to store any of the encryption keys in cleartext, so simpleencryption with a local key is best. It sends the encrypted recordingkey to the DVR 1003.

The DVR 1003 decrypts the recording key using the strong key that itshares with the media server 1002 and stores the recording key. The DVR1003 can optionally encrypt the recording key using a local key beforestorage. The media server 1002 sends the recorded content that it hasstored locally to the DVR 1003. The recorded content has already beenencrypted when it was originally stored locally by the media server1002. The media server 1002 sends the recorded content withoutdecrypting the content.

The DVR 1003 writes the recorded content directly to its storage devicewithout decoding it. When the DVR 1003 plays the recorded content, itdecodes the content on the fly using the recording key. Referring toFIG. 19, the user can select the program information screen 1901 to seeif the program is still transferring. The user can play the program byselecting Play option 1902 while the transfer is in progress (asdescribed above) or stop the transfer using Stop transfer option 1903.

If the media server 1002 sends an unencrypted recording to the DVR 1003,it creates a random recording key that will be used to encrypt therecording and encrypts the recording key using the strong key. The mediaserver 1002 sends the encrypted recording key to the DVR 1003.

The DVR 1003 decrypts the recording key using the strong key that itshares with the media server 1002 and stores the recording key. The DVR1003 can optionally encrypt the recording key using a local key beforestorage. The media server 1002 sends the recorded content that it hasstored locally to the DVR 1003. The recorded content was not encryptedwhen it was originally stored locally by the media server 1002. Themedia server 1002 sends the recorded content, encrypting the content asit sends the content.

The DVR 1003 writes the recorded content directly to its storage devicewithout decoding it. When the DVR 1003 plays the recorded content, itdecodes the content on the fly using the recording key.

Note that if content copyrights are a concern, the DVR 1003 does notneed to store the content on its storage device. It simply plays ordisplays the content immediately. If the content is encrypted, the DVR1003 decrypts the content on the fly.

The approach described above performs equally well in a local network asit does across the Internet.

H. Preserving Certificate Coherency

Referring again to FIG. 11, the creation of a strong key takes many CPUcycles. In one approach, DVR 1101 may be required to create and store aplurality of strong keys for future use at the time that it isdesignated as the media server. Further, the receiving DVR requires manyCPU cycles to decrypt the strong key upon receipt. This significantlyslows down the DVR's overall performance. The techniques herein save theDVR 1101 the added burden of creating a new strong key whenever a DVR1102 reboots or is restarted. It also saves DVR 1102 the burden ofdecrypting the strong key after reboot or restart.

The DVR 1101 originally creates a strong connection key, stores it inits local cache 1103, and encrypts the key using the public key of theother DVR 1102. The DVR 1101 sends the encrypted strong key to the DVR1102. The DVR 1102 decrypts the strong key and stores the key in itslocal cache 1104 along with the encrypted strong key and the machineserial number of DVR 1101.

If the DVR 1102 reboots or is restarted, it does not know what itsstatus is in the network. It may have been down for a few seconds or itmay have been transplanted from another network. The DVR 1102 requeststhe strong key from the DVR 1101 designated as the media server. The DVR1101 sends the strong key that it has stored in its local cache 1103, orif the DVR 1102 has not had a strong connection established with the DVR1101, creates a new strong key. The strong key is encrypted using thepublic key of the DVR 1102 and is sent to the DVR 1102.

When the DVR 1102 receives the encrypted strong key, it checks the localcache 1104 for an entry from the DVR 1101 and, if it finds one, it doesa bitwise comparison with the encrypted key in the local cache 1104. Ifthe two keys are the same, then the DVR 1102 uses the previouslydecrypted key stored in the local cache 1104. Otherwise the DVR 1102decrypts the newly sent key and stores the encrypted key, decrypted key,and DVR 1101 machine serial number in a new entry in the local cache1104. This way the long decryption step is avoided except whenabsolutely necessary.

I. Internet Media Downloading

To facilitate Internet media downloading from a server to a DVR, FIG. 12shows a modification of the digital certificate shown in FIG. 9. Also,referring again to FIG. 7, the service center 130 creates thecertificate 901 which is distributed to DVRs 110, 770. The DVR 110, 770will recognize a service entry using a specially-prefixed serial numberin the service's serial number field 903, for example: FFFxxxxxxxxxxxx,where the “xxxxxxxxxxxx” is used to provide additional information, suchas version numbers, service provider, etc. The display name 902 is setto something indicative of the service, such as “Special Videos”.Instead of a direct public key, the key field 1204, 1206 is filled inwith a fully qualified domain name of the access point for the server.

The certificate 901 can contain a mix of service server information andpeer unit information. The expiration date 907 and digital signature 908remain the same.

Thus, the service center 130 can place information in the fields in all,or a group, of certificates to name the same or different servers, etc.

A DVR 110 recognizes the service serial number in the certificate andsends a ping to the server using the domain name in the key field, forexample, the key field 1204, to see if it is reachable. When a new DVRconnects, the server looks up the DVR's public key and uses that togenerate any other needed keys. The DVR does not need to possess a keyfor the server; the server generates the strong key for the session andencrypts the strong key with the DVR's public key. It then passes theencrypted strong key to the DVR.

Once communication is established the DVR 110 can then query the serverfor content.

The server synthesizes the appropriate metadata to describe what it hasavailable and sends it to the DVR 110. Since the metadata issynthesized, it can be uniquely created on a per-DVR basis. For example,a DVR owner may sign up for different kinds of services, such ashistory, drama, comedy, etc.

Alternatively, the server can instruct the DVR 110 to send itspreference vector to the server, which the server uses to synthesize theappropriate metadata. The DVR's preference vector contains the user'sviewing habits, e.g., what the user has indicated that he does and doesnot like, what he has consistently recorded using options such as aseason pass subscription. The server does not store the preferencevector information; it simply discards the information after use. Thispreserves the user's privacy and makes sure the preferences are alwayskept on the DVR 110.

The standard video, music, and photo transfer interface is used asdescribed above. FIG. 16 shows a Now Playing screen 1601 where availablecontent from the DVR itself and other accessible servers and DVRs aredisplayed 1602. An entry for content from a service has its associatedname from the certificate listed. In the same manner, content fromanother DVR is listed using the name 1602 that the user has associatedwith it, if any exists. This way, the user knows the source of thecontent. FIG. 17 shows the content screen 1701 displaying the name ofthe content source 1702. FIGS. 20 and 21 show a music content screen2001 and photo content screen 2101.

Referring to FIG. 13, DVRs that are interested in downloading contentfrom a server 1301, ping the server 1301. The server 1301 runs the pingservice, responding to requests from DVRs as they come in. This allowsthe server 1301 to maintain a record 1302 of all DVRs that are “signedup” to download video. The record 1302 can later be audited to ensure,for example, that there are no clones of DVRs accessing the downloadablevideo from another IP address. The record 1302 can also be used forbilling purposes to track the length of time a user has his DVR 1303signed up to download video.

When the user selects an entry from a server 1301 to transfer to a DVR1303, the DVR 1303 contacts the server 1301 and requests the appropriatemedia object. At that point, the server 1301 can record 1302 that theprogram is being downloaded, which may also include an entry into abilling system, etc.

The records can be queried on the service center's Web site by a user1304 so he can easily check his bill.

Referring to FIG. 14, a domain-name redirector 1402 can be used thatredirects a connection from a DVR 1401 to one of a group of third partyservers 1403, 1404, 1405. Redirection may occur based on load, thedomain-name prefix used, etc. This allows the service center to redirecta request to another company's server. Redirection may involve a fee orrevenue share in various embodiments.

A domain name redirector 1402 can reside on each third party server1403, 1404, 1405, so a request from a DVR 1401 can be redirected by thethird party server itself. The DVR 1401 requests a connection with thirdparty server 1403. Third party server 1403 “delegates” itsresponsibilities to third party server 1404 by redirecting the requestfrom the DVR 1401 to third party server 1404. DVR 1401 then contactsthird party server 1404 for its content requests. This allows a thirdparty server to judge by itself if is overloaded or cannot handle arequest for any reason.

J. Using a DVR as an Encryption Pipeline

Referring to FIG. 15, content to be provided to a DVR 1503, 1504, 1505can initially be produced by a content server 1501, such as a thirdparty content server. The content server 1501 does not have access toany information about the DVR's encryption techniques or architecture. ADVR 1502 is used to encode and encrypt the content. The DVR 1502 has afast network engine and functions as an “encryption pipeline”. Data issent from the content server 1501 to the DVR 1502. The DVR 1502 encodes(if needed) and encrypts the data while writing the data to its localstorage device. The DVR 1502 then reads the data from the local storagedevice without decrypting, and sends the data over the network to atarget DVR selected from among DVR 1503, 1504, 1505.

Another approach provides the third party content server with securetransmission of its content. Data is sent from the content server 1501to the DVR 1502 using the content server's encryption technique. The DVR1502 decrypts the data using the content server's decryption technique.The DVR 1502 then encodes (if needed) and encrypts (using the DVR'sencryption technique) the data while writing the data to its localstorage device. The DVR 1502 then reads the data from the local storagedevice without decrypting, and sends the data over the network to atarget DVR selected from among DVR 1503, 1504, 1505.

This ensures that a third party content supplier does not have access toany sensitive information about the DVR crypto chip, encryptiontechniques, or addressing schemes. It further reduces the time to marketand cost of incorporating third party suppliers into the content servernetwork.

K. Accessing Content Via Email

As described above, the media server in any of the foregoing embodimentscan be a PC, DVR, or any other mechanism that can serve content. Theapproaches described herein allow the DVRs, as clients of the mediaserver, to access multimedia content such as music, video, and photocontent stored on media servers. However, because the DVRs and mediaservers may have access to the Internet, the content need not originatenor be physically housed on any given media server.

Accordingly, content can be made available to DVR users by arranging fora server to process a special file containing:

-   -   Actual content (in the form of JPEG, MP3, or MPEG files, for        example).    -   DVR configuration settings, for example, recording schedules,        database modifications, content preferences, etc.    -   “Links” to another server or to the content stored on another        server, located potentially anywhere on the Internet.

Such files can be provided to the DVR users via email or Internetdownload. Two example scenarios are described below that demonstrate howcontent can be sent via email to a DVR.

Referring to FIGS. 22 and 23, a typical household DVR setup 2201 isshown. Assume only the media server 2202 has access to the Internet2205. An email author 2204 creates a content file with authoringsoftware. The file, for example, contains the actual binary data forseveral images in JPEG format (it can contain any type of content). Thecontent file is emailed as an attachment to a user who accesses emailfrom the same computer running the media server 2202. Messagecommunication mechanisms other than email may be used in alternativeembodiments.

The user reads the email and, if he is interested in the content, theuser selects the attached content file, invoking the media server 2202to process the content file. The media server 2202 adds informationabout the images to an internal database from which container (metadata)information and JPEG data can be later generated.

The user goes to his DVR 2203 and accesses the “Music & Photos” featurevia his television set, causing the DVR 2203 to request containerinformation from the media server 2202. Among the other containers ofavailable content shown in photo content screen 2101 (FIG. 21), the usercan now access one with images from the content file. When the userissues the command to view one of the images, the DVR 2203 makes arequest to the media server 2202, which consults its internal databaseto render the appropriate JPEG data and pass the data to the DVR 2203.The DVR 2203 displays the image to the user and does not store the imageon its local storage device. The user can use trickplay functions on themultiple photo files such as fast forward, pause, reverse, play(slideshow), etc.

In FIG. 23, a household DVR setup 2301 is shown where both the DVR 2303and media server 2302 have access to the Internet 2305. An author 2304creates a content file with authoring software. The file links to one ormore content files, such as MP3 music files, housed on the contentserver 2306 and served via HTTP. The content file is emailed as anattachment to a user who (ideally) accesses email from the same computerrunning the media server 2302.

The user reads the email and, if he is interested in the content, theuser selects the attached content file, invoking the media server 2302to process the content file. The media server 2302 adds informationabout the content files to an internal database from which containerinformation can be later generated.

The customer goes to his DVR 2303 and accesses the “Music & Photos”feature, causing the DVR 2203 to request container information from themedia server 2302. Among the other containers of available content shownin music content screen 2001 (FIG. 20), the customer can now access onewith music served by the content server 2306. When the user issues thecommand to play one of the music files, the DVR 2303 accesses thecontent server 2306 directly over the Internet 2305 to retrieve theappropriate data. The user can use trickplay functions on the musicfiles such as fast forward, pause, reverse, play, etc. The progress ofthrough the music is displayed to the user through a connectedtelevision set using a replay bar as shown in FIG. 8. The DVR 2303 doesnot store the music on its storage device for copyright protection.

As noted above, the two preceding examples can be used for any type ofcontent that a DVR can use or display. If configuration information isreceived, the DVR 2303 will store the configuration information on itslocal storage device and use the configuration information to configureitself. If video is received, the DVR 2303 can store the video contenton its local storage device for later playback by the user. The user canuse trickplay functions on the video content such as fast forward,pause, reverse, play, slow play, frame step, etc.

DVR users could use the approach to share content with each other viaemail. For example, one user could send to another user a content filewith links to personal photos housed on the first customer's PC.

The approach herein can be further useful for third party vendors tomarket content to DVR users via email. For example, a record label couldpromote a new album by sending a content file with links to MP3 filescontaining sample songs.

Third party partners can use the approach herein to deliver product toDVR users via email. For example, a film processing lab could email acontent file containing digitized photos purchased online by a DVR user.

In the foregoing specification, the invention has been described withreference to specific embodiments thereof. It will, however, be evidentthat various modifications and changes may be made thereto withoutdeparting from the broader spirit and scope of the invention. Thespecification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense.

1-32. (canceled)
 33. A method for sharing media content, the methodcomprising: storing a media stream and metadata associated with themedia stream in a memory of a first device, wherein the first device islocated on a network in a home; detecting the presence of a seconddevice located on the network in the home; receiving a media transfercriterion associated with the second device; determining whether themetadata associated with the media stream matches the media transfercriterion; in response to determining that the metadata associated withthe media stream matches the media transfer criterion, transferring themedia stream and a portion of the metadata from the memory of the firstdevice to the second device via the network in the home.
 34. The methodof claim 33, further comprising: identifying a profile of a userassociated with the second device; determining the criterion based onpreferences of the user stored in the profile.
 35. The method of claim33, wherein storing the media stream in the memory of the first devicecomprises, encrypting the media stream before storing the media streamin the memory of the first device.
 36. The method of claim 35, whereintransferring the media stream from the memory of the first device to thesecond device comprises: retrieving the media stream from the memory ofthe first device; and transferring the media stream to the seconddevice, without decrypting the media stream, via the network in thehome.
 37. The method of claim 36, further comprising, transmitting, tothe second device, a key for decrypting the transferred media stream.38. The method of claim 33, wherein the criterion is received by thefirst device from the second device.
 39. The method of claim 33, whereinthe media stream is a first media stream, and wherein the metadata isfirst metadata, further comprising: storing a second media stream andsecond metadata associated with the second media stream in the memory ofthe first device; determining whether the second metadata associatedwith the stored second media stream matches the media transfercriterion; and in response to determining that the second metadataassociated with the second media stream matches the media transfercriterion, transferring, via the network in the home, a portion of thesecond metadata associated with the second media stream to the seconddevice without transferring the second media stream from the memory ofthe first device.
 40. The method of claim 39, further comprising:receiving, from the second device, a request for the stored second mediastream; and in response to receiving the request, transferring thestored second media stream to the second device.
 41. The method of claim40, wherein the request specifies a position within the stored secondmedia stream, and wherein transferring the stored second media stream tothe second device comprises: identifying a first portion of the storedsecond media stream following the position and a second portion of thestored second media stream preceding the position; and transferring,from the memory of the first device, the first portion of the storedsecond media stream without transferring the second portion of thestored second media stream.
 42. The method of claim 33, wherein themedia stream is received by the first device via a tuner associated withthe first device.
 43. A system for sharing media content, the systemcomprising control circuitry configured to: store a media stream andmetadata associated with the media stream in a memory of a first device,wherein the first device is located on a network in a home; detect thepresence of a second device located on the network in the home; receivea media transfer criterion associated with the second device; determinewhether the metadata associated with the media stream matches the mediatransfer criterion; in response to determining that the metadataassociated with the media stream matches the media transfer criterion,transfer the media stream and a portion of the metadata from the memoryof the first device to the second device via the network in the home.44. The system of claim 43, wherein the control circuitry is furtherconfigured to: identify a profile of a user associated with the seconddevice; determine the criterion based on preferences of the user storedin the profile.
 45. The system of claim 43, wherein the controlcircuitry is further configured, when storing the media stream in thememory of the first device, to encrypt the media stream before storingthe media stream in the memory of the first device.
 46. The system ofclaim 45, wherein the control circuitry is further configured, whentransferring the media stream from the memory of the first device to thesecond device, to: retrieve the media stream from the memory of thefirst device; and transfer the media stream to the second device,without decrypting the media stream, via the network in the home. 47.The system of claim 46, wherein the control circuitry is further totransmit, to the second device, a key for decrypting the transferredmedia stream.
 48. The system of claim 43, wherein the criterion isreceived by the first device from the second device.
 49. The system ofclaim 43, wherein the media stream is a first media stream, and whereinthe metadata is first metadata, and wherein the control circuitry isfurther configured to: store a second media stream and second metadataassociated with the second media stream in the memory of the firstdevice; determine whether the second metadata associated with the storedsecond media stream matches the media transfer criterion; and inresponse to determining that the second metadata associated with thesecond media stream matches the media transfer criterion, transfer, viathe network in the home, a portion of the second metadata associatedwith the second media stream to the second device without transferringthe second media stream from the memory of the first device.
 50. Thesystem of claim 49, wherein the control circuitry is further configuredto: receive, from the second device, a request for the stored secondmedia stream; and in response to receiving the request, transfer thestored second media stream to the second device.
 51. The system of claim50, wherein the request specifies a position within the stored secondmedia stream, and wherein the control circuitry is further configured,when transferring the stored second media stream to the second device,to: identify a first portion of the stored second media stream followingthe position and a second portion of the stored second media streampreceding the position; and transfer, from the memory of the firstdevice, the first portion of the stored second media stream withouttransferring the second portion of the stored second media stream. 52.The system of claim 43, further comprising a tuner configured to receivethe media stream.